During the infancy of the World Wide Web (“WWW” or the “Web”), hyper-text markup language (“HTML”) was used almost exclusively for the presentation of Web pages within a Web browser. However, due to the limitations of HTML, technologies were created that enable the presentation of more robust information than permitted by HTML. These technologies, such as JAVA from SUN MICROSYSTEMS and ACTIVEX from MICROSOFT CORPORATION, allow client-side browser objects to be created that provide functionality not possible through the use of only HTML. JAVA applications (“applets”) and ACTIVEX controls executing within a Web browser can provide rich graphics, animation, dynamic content, continuously updated content, and other types of robust data presentation not previously possible using only HTML. These types of client-side browser objects have greatly enhanced the presentation capabilities of today's Web browsers.
One difficulty encountered when utilizing client-side browser objects occurs when it is necessary to have two client-side objects communicate with one another. For instance, it may be desirable to have one object retrieve and display a list of available automobiles. When a user selects the name of an automobile, the name may be transmitted from the first object to a second object which is responsible for retrieving a graphic image of the selected automobile and for displaying the image within the Web browser. In order for this type of inter-object communication to occur, a programmer would typically create each of the objects in a manner that allows them to communicate by directly calling functions on each other. However, if an object is not present on the Web page or if an incorrect version of the called or calling object is present, the intended interaction between objects may not take place.
Another way for client-side objects to communicate is through the use of an intermediary object. For example, using Web Part Site technology from MICROSOFT CORPORATION, an intermediary object is included with each Web page. The intermediary object, called the Web part service component (“WPSC”) provides a framework that allows, among other things, client-side objects configured for use with the WPSC (called “Web parts”) to communicate with one another through the WPSC. By using the WPSC, objects can make calls into the framework for communicating with other objects. These calls are received by the WPSC and passed to other objects that have registered to receive such messages. The WPSC provides a standard framework for inter-object communication and frees programmers from having to write objects that directly communicate with each another.
Most client-side objects that utilize a central intermediary, such as the WPSC, implement a predefined and fixed set of object interfaces for communicating with the WPSC and other objects. However, in order to add support for additional interfaces in the future, the object may need to be reprogrammed to implement the desired interfaces. Alternatively, an object could support all of the available interfaces, but this requires the utilization of a substantial amount of resources for interfaces that may not even be used. Moreover, if all of the available interfaces were supported, there would still be no easy way for a solution provider to customize the implementation of the interfaces for a particular application without reprogramming the object.
Accordingly, there is a need for a method, system, and apparatus that allows object interfaces on client-side objects for inter-object communication to be dynamically implemented and customized at runtime. It is with respect to these considerations and others that the present invention has been made.